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SYSTEMS AND METHODS FOR THE 
AUTOMATIC REGISTRATION OF DEVICES 

This application claims the benefit of U.S. 
Provisional application No. 60/230,319, filed September 
6, 2000. 

Background of the Invention 

This invention relates to systems and methods 
for registering devices at remote sites, and more 
particularly, this invention relates to systems and 
methods for automatically registering devices at remote 
sites. The remote sites may be accessed by a user to 
control the registered devices. 

Much of today's technology involves the use 
of equipment that is controlled from a remote location. 
Typically, before such equipment can be used, the 
equipment must first be registered at a remote 
location. 

For example, cellular phones must be 
registered with a cellular phone service provider 
before being used.- Users may purchase cellular phones 
from stores, but unless the phones are activated by the 
cellular service provider, they are useless. The 
activation involves the user or a retailer providing 
particular information about the user and his or her 
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cellular phone to a cellular service provider. Users 
typically register cellular phones by calling the 
service provider and providing registration information 
using a separate telephone or by submitting to the 
5 service provider electronic forms (e.g., using a modem- 
to-modem connection) . In either case, the probability 
for error is high given the human interaction involved. 
Furthermore, much time must be expended in these 
procedures . 

10 It is therefore an object of the present 

invention to provide improved systems and methods for 
remotely registering devices. 
Summary of the Invention 

This and other objects of the invention are 

15 accomplished in accordance with the principles of the 
present invention by providing an automatic 
registration system having monitoring modules that 
communicate with remote sites. Devices at one or more 
locations may interface with the monitoring modules. 

20 One or more monitoring modules and their associated 
interfaced devices may be referred to herein as 
"installations." Devices may include, for example, 
video cameras, still cameras, motion sensors, audible 
detectors, any suitable household appliances, or any 

25 other suitable device. Monitoring modules may be 
stand-alone devices, software applications, any 
suitable combination of software and hardware, or any 
other suitable architecture. Monitoring modules may 
communicate with one or more remote sites via a 

30 suitable communications network using any suitable 

communications protocol. The monitoring modules and 
remote sites may use a registration protocol to 
transmit registration information. The registration 



information may get stored in a database at the remote 
site. The registration protocol may be a subset of the 
communications protocol used between the monitoring 
modules and the remote sites. 

An installation, any of its components, or 
both may be associated with a particular user account. 
The account holder may be any suitable entity, such as, 
for example, a person, a corporate entity, a family, a 
governmental entity, any suitable organization, or any 
other suitable entity capable of maintaining an 
account . 

Association of an installation, installation 
elements, or both with corresponding user accounts may 
take place at the remote site. The remote site may 
make the association using any suitable database 
construct that may serve to cross-reference the 
installation, installation elements, or both with user 
accounts. For example, any suitable relational 
database schema with suitable keys may be used. 

Monitoring modules may be assigned or may 
generate a globally unique monitoring module 
identification, corresponding password, model 
identification code, and transaction identification for 
use during the registration process. The monitoring 
module may automatically detect any devices that are 
interfaced with it. The monitoring module may obtain 
from the device any necessary or useful data in 
registering the devices as well as itself. The 
identification information and device information may 
be communicated to the remote site via the 
communications network . 

Remote sites may include any suitable 
computer-based server or combination of servers such 
as, for example, web servers and database servers. 
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Monitoring modules at installations may exchange 
registration protocol messages with remote sites using 
any protocol suitable to the chosen communications 
network. In an Internet-based approach, for example, 
5 installations and remote sites may exchange 
registration messages using HTTP (which may be 
processed by the web server at the remote site) over 
TCP/IP (e.g., IP version 6, IP version 4, etc.) over a 
communications network. Servers such as a web server 
10 and a database server, may interact through the use of 
API functions. 

The remote sites may validate received 
registration protocol messages. Where the registration 
messages contain no errors, or where errors are 
15 correctable by the remote site, the registration 
information contained therein may be stored in a 
database in the database server. A confirmation 
message may be communicated from the remote site to the 
installation that may include either an ACK code that 
20 denotes successful completion of the registration 

process or a NAK code that may denote an unsuccessful 
registration attempt. 

Devices may be automatically detected by a 
monitoring module. Automatic detection may be 
25 implemented using any suitable approach. For example, 
the monitoring module may communicate a handshake 
signal to all of its interface ports. If the 
monitoring module receives a response, then a device 
may be detected at the port from which the response was 
30 received. In another suitable approach, a particular 
pin of the interface port may be used to denote whether 
power is being sent through the port (i.e., to power a 
device) . If the value of the pin is high, for example, 
the monitoring module may deduce that a device is 



coupled to the monitoring module at that port. In 
another suitable approach, a user may proactively have 
the monitoring module detect a particular device. For 
example, the user may press a button on the device that 
may cause the device to send a communication to the 
monitoring module, thus alerting the monitoring module 
of the device's presence. 

In one suitable embodiment of the present 
invention, virtual representations of devices may be 
registered. Virtual representation may be made up of 
resources, which may be, in turn, made up of 
components. Components may be used to indicate the 
state of a corresponding physical device component. 
Components may be used to change the state of a 
corresponding physical device component. Virtual 
representations of devices may be accessed by users who 
are authorized to access the virtual representations. 
These users may be those users that are associated with 
the user account with which the corresponding devices 
(of the virtual representations) are also associated. 

New devices or monitoring modules may be 
added to a registered installation and automatically 
detected and registered by a new object discovery 
process. New object discovery may be conducted by 
registered monitoring modules, the remote site, or by 
any other suitable element of the automatic 
registration system. The new object discovery may be 
conducted on a continuous basis or on a periodic basis. 
If desired, the new object discovery need not be 
automatic, but may be instantiated by the user (e.g., 
through simple software or hardware manipulation) . 
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Brief Description of the Drawings 

FIG. 1 is a block diagram of an illustrative 
automatic registration system in accordance with an 
embodiment of the present invention . 
5 FIG. 2 is a block diagram of some of the 

components of the illustrative automatic registration 
system of FIG. 1 in accordance with an embodiment of 
the present invention. 

FIG. 3 is a block diagram of some of the 
10 components of the illustrative automatic registration 
system of FIG. 1 in accordance with an embodiment of 
the present invention. 

FIG. 4 is a flow chart of illustrative steps 
involved in associating an installation with a user 
15 account during the registration process in accordance 
with an embodiment of the present invention. 

FIG. 5 shows an illustrative registration 
display screen for a service agreement in accordance 
with an embodiment of the present invention. 
20 FIG. 6 shows an illustrative registration 

display screen for requesting information from a user 
in accordance with an embodiment of the present 
invention . 

FIG. 7 shows an illustrative registration 
25 display screen for showing user-assigned names for 

particular devices in accordance with an embodiment of 
the present invention. 

FIG. 8 shows an illustrative registration 
display screen for allowing a user to name an 
30 installation being registered in accordance with an 
embodiment of the present invention. 

FIG. 9A shows an illustrative registration 
display screen for instructing the user on how to 



attach devices to a monitoring module in accordance 
with an embodiment of the present invention. 

FIG. 9B is a flow chart of illustrative steps 
involved with using handshaking for automatic device 
detection in accordance with an embodiment of the 
present invention . 

FIG. 9C is a flow chart of illustrative steps 
involves with detecting data streams for automatic 
device detection in accordance with an embodiment of 
the present invention. 

FIG. 10 shows an illustrative registration 
display screen for notifying the user of detected 
devices and to allow the user to rename a device in 
accordance with an embodiment of the present invention. 

FIG. 11 shows an illustrative registration 
display screen that allows the user to provide 
information on the communications network being used 
and to test the connection in accordance with an 
embodiment of the present invention. 

FIG. 12 is a block diagram of a illustrative 
identification information that may be generated by a 
monitoring module in accordance with an embodiment of 
the present invention. 

FIG. 13 is a flow chart of illustrative steps 
involved in the automatic registration of an 
installation in accordance with an embodiment of the 
present invention . 

FIG. 14 shows illustrative commands, their 
parameters, and validity checks in accordance with an 
embodiment of the present invention. 

FIG. 15 is an illustrative database schema 
that may be used by the database server of FIG. 1 in 
accordance with an embodiment of the present invention. 
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FIG. 16 is a diagram showing an illustrative 
relationship between the database and the web server in 
accordance with an embodiment of the present invention. 

FIG. 17 shows an illustrative registration 
5 display screen that displays the assigned notification 
action for a particular event in accordance with an 
embodiment of the present invention. 

FIG. 18 is a flow chart of illustrative steps 
involved in registering virtual representation in 
10 accordance with an embodiment of the present invention. 

FIG. 19 is a flow chart of illustrative steps 
involved in the automatic detection and registration of 
new devices in accordance with an embodiment of the 
present invention . 



15 Detailed Description of the Invention 

FIG. 1 shows an illustrative system 10 in 
accordance with the present invention. For purposes of 
clarity, and not by way of limitation, an illustrative 
client-server based embodiment of the present invention 

20 is herein described. System 10 may include an 

installation 12 and a remote site 14 that may be linked 
via a communications network 16. In practice, there 
may be more than one remote site 14 and installation 
12, but only one each is shown to avoid over- 

2 5 complicating the drawing. Remote site 14 may be any 

suitable remote site that may include equipment such 
as, for example, one or more servers, mainframes, 
personal computers, or any other suitable computer- 
based equipment. Remote site 14 may include a network 

3 0 of suitable computers that may be interconnected in any 

suitable way, such as, for example, through a local 
area network, wide area network, telephone network, 
cable television network, Intranet, Internet, or any 



- 9 - 



other suitable wired or wireless communications 
network. Communications network 16 may be any suitable 
communications network, such as, for example, a local 
area network, wide area network, telephone network, 
5 cable television network, Intranet, Internet, or any 
other suitable wired or wireless communications 
network. Some suitable wireless communications 
networks may be global system for mobile communications 
(GSM) , time-division multiple access (TDMA) , code- 

10 division multiple access (CDMA) , Bluetooth, or any 
other suitable wireless communication networks. 
Installation 12 and remote site 14 may communicate over 
communications network 16 using any suitable protocol 
or protocol stack. For example, installation 12 and 

15 remote site 14 may communicate via a transmission 

control protocol/ Internet protocol (TCP/IP) environment 
using, for example, IP version 4 or IP version 6 (that 
supports 128 -bit network addressing) and a hypertext 
transfer protocol (HTTP) . In another approach, 

2 0 universal plug and play (UPnP) technology may be used 
to allow communication between installation 12 and 
remote site 14. Any suitable request-response type of 
protocol and socket-based packet transport stack, or 
suitable peer-to-peer communications approach may be 

25 used as desired. 

Installation 12 and remote site 14 may 
communicate using any suitable communications. 
Communications may include, for example, commands, 
requests, messages, remote procedure calls (e.g., using 

30 a proxy-stub pair) , or any other suitable client-server 
or peer-to-peer communication. Communications may also 
involve, for example, complex communications between 
application constructs running on installation 12 and 
remote site 14. Objects running on the client and 
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server may, for example, communicate using an Object 
Request Broker (ORB) . Transmitted information may, for 
example, be encapsulated as COM objects or Javabeans 
and persisted to files that are transmitted over a 
5 remote access link. In another suitable approach, 
access communications may include hypertext markup 
language (HTML) formatted markup language documents 
(e.g., web pages), that are exchanged between 
installation 12 and remote site 14 via ISP 23 and 

10 communications link 16. For example, communications 

may consist of a series of HTTP posts and responses in 
which the parameters for the transmissions may be sent 
as name/value pairs in the normal post method. In 
order to achieve the result of transmitting multiple 

15 commands in a single command string, numbered commands 
may be parsed out and executed at remote site 14 . 
Remote site 14 may be responsible for parsing the 
command string into individual commands and executing 
each of those commands. In order to achieve this task 

20 of parsing the commands, remote site 14 may utilize a 
script language and interpreter such as Personal Home 
Page Tools (PHP) which is embedded within a Web page 
along with its Hypertext Markup Language (HTML) . For 
example, before a page is sent to the requesting user, 

2 5 the Web server may call PHP to interpret and perform 

the operations called for. Other similar technologies 
may also be utilized such as JavaScript, Microsoft's 
VBScript, or any other applicable script interpreter. 
If desired, any other suitable client-server or peer- 

3 0 to-peer based approach may be used. 

Installation 12 may be operated by a local 
user. Installation 12 may include one or more nodes. 
For purposes of illustration, FIG. 1 illustrates an 
approach having two nodes, first user node 18 and 
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second user node 20. It should be understood that 
nodes 18 and 20 may be located at a single location, 
such as the user's main residence. If desired, nodes 
may be located across more than one location. For 
example, one node may be in a user's main residence and 
another at the user's vacation house. 

In one embodiment of the present invention, 
user node 18 may include a client device 22 that may be 
connected to communications network 16. In Internet- 
based approaches, such as, for example, as in the 
embodiment shown in FIG. 1, client device 22 may be 
connected to the Internet via an Internet service 
provider (ISP) 23. Client device 22 may be any device 
suitable for communicating with remote site 14 via 
communications network 16. For example, client device 
22 may be a computer, a personal digital assistant 
(PDA) , a terminal, a set-top box, or any other suitable 
device that provides access to remote site 14 via 
communications network 16. Client device 22 may 
include, for example, an Internet browser application 
26 that may be used to access web pages via 
communications network 16. In other suitable 
approaches, client device 22 may run a client 
application that provides locally generated displays 
propagated with a format obtained using any suitable 
client-server or peer-to-peer scheme. 

Client device 22 may communicate with ISP 23 
or directly with communications network 16 using any 
suitable communications link. For example, the link 
may include a telephone dial-up link, digital 
subscriber lines (DSL), a cable modem link (e.g., a 
data over cable service interface specification 
(DOCSIS) ) , a satellite link, a computer network link 
(e.g., Ethernet link, Tl line, etc.) or any other 
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suitable communications link or combination of 
communications links . 

Remote site 14 may include one or more 
servers such as, for example, web server 4 6 and 
database server 48. Database server 48 may maintain 
database 58. In other suitable approaches, such as 
non- Internet based approaches, remote site 14 may 
include an application server and any other suitable 
server or combination of servers. As herein used, the 
term "server" is not limited to a distinct piece of 
computing hardware or storage hardware, but may also be 
a software application or a combination of hardware and 
software. For example, one computer may have software 
that enables the computer to act as both a web server 
and as a database server. 

In some suitable approaches, remote site 14 
may provide displays or display definitions to client 
device 22. In the Internet-based approach of FIG. 1, 
for example, web server 46 may generate static and 
dynamic web pages from data supplied by database server 
48. Web page 47 may be viewed by a user using Internet 
browser 26 running on client device 22. 

Software applications interfacing 
installation 12 with remote site 14 may be created 
using any suitable platform and/or software development 
tools. For example, Java 2 Enterprise Edition, 
Javabeans, component object model (COM) based 
technologies (e.g., ActiveX, object linking and 
embedding (OLE) , etc.), Javascript, Visual Basic, C, 
C++, scripting languages, or any combination of these 
or other suitable development tools may be used in 
creating the software interface between installation 12 
and remote site 14 (e.g., web-page interface). Any 
combination of these or other suitable development 



tools may be used in preparing any other software 
modules or applications for use in any other suitable 
facet of the present invention. 

Remote site 14 may function as the master 
controller of the system shown in system 10. In 
addition, users may access the system shown in system 
10 via any computer, monitoring module, or remote user 
access device linked to communications network 16. 
Remote user access devices (such as remote user access 
device 17 in FIG. 1) may include, for example, personal 
digital assistants, cellular telephones, set-top boxes, 
personal computers, or any other suitable device a user 
may use to access remote site 14 via communications 
network 16 . 

Monitoring modules 2 8 may serve as an 
interface between remote site 14 and at least one 
connected device 32. Monitoring modules 28 may be any 
suitable hardware, software, or a combination thereof 
and may be included at any point within the system. 
For example, monitoring module 2 8 may be a software 
application running on client device 22 or a separate 
piece of hardware that may be connected to client 
device 22 (as shown at node 18) or partially 
implemented as software on client device 22 and a 
separate piece of hardware. In some embodiments, 
monitoring module 28 may be a stand-alone appliance (as 
shown at node 20) connected to communications network 
16, operating separately and independently from client 
device 22 . Each monitoring module may be shipped with 
a model identification code, or with the capacity to 
generate such a code, that may serve to identify each 
particular monitoring module's model type. 

One or more monitoring modules may be 
installed at one or more locations. Monitoring modules 
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displays, washers/driers, microwave ovens, cooking 
ranges, car alarms, plant watering devices, sprinkler, 
thermostats, carbon monoxide sensors, humidistats, rain 
gauges, video cassette recorders, radio tuners, or any 
5 other suitable device and the like. 

One or more notification devices, such as 
pager 43, may also be incorporated into the system. As 
illustrated in FIG. 1, pager 43 is in wireless 
communication with a wireless or cellular transmitter 

10 44 associated with remote site 14. Other suitable 
notification devices include, for example, e-mail 
clients, wireless hand-held computers, wireless 
wearable computer units, automatic web notification via 
dynamic web content, telephone clients, voice mail 

15 clients, cellular telephones, instant messaging 
clients, and the like. 

System 10 provides users with opportunities 
to remotely control and monitor devices 32 using remote 
user access devices 17 via communications network 16. 

20 In the example of FIG. 1, users may control devices 32 
that are interfaced with monitoring modules 2 8 at node 
18 and devices 32 interfaced with monitoring module 28 
at node 20. In practice, there may be a single node, 
or more nodes, depending on, for example, the user's 

25 equipment, number of sites, or other suitable 
parameters. In practice, a suitable system 
architecture and communications network 16 may allow 
users, or anyone that users permit, to readily monitor 
and control monitoring modules 2 8 from any location 

30 using any suitable device that is capable of 

communicating with remote site 14 via communications 
network 16. 

In another suitable approach, users may 
access installation 12 using remote user access devices 
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17 without the use of remote site 14. For example, 
remote user access devices 17 may be used to 
communicate with monitoring modules 28 of installation 
12 via communication network 16 and ISP 23 . If 
desired, two-way communications may be implemented 
using this approach. Remote user access device may 
access installation 12 using, for example, special IP 
addresses assigned to a particular monitoring module, 
node, installation, or any other suitable element of 
the installation. The use of IP addresses is merely 
illustrative. Any other suitable addressing may be 
used to allow access to an installation from a remote 
used access device. 

Devices 3 2 may be programmed at the 
installation in terms of how they respond to certain 
events (e.g., what does the camera do when the contact 
sensor is triggered?) . Alternatively, devices 32 may 
be programmed from a remote location using remote user 
access device 17, for example. The programming may be 
stored in devices 32, monitoring modules 28, or at 
remote site 14 . 

The following examples of the uses of 
illustrative devices will illustrate the operation of 
the present invention. For example, contact sensor 4 0 
of FIG. 1 may be associated with the front door (not 
shown) of a remote location associated with second node 
20. Contact sensor 40 may be configured to trip 
whenever the front door is opened. Camera 34 is also 
positioned to view the front door location and may be 
programmed to take a digital picture whenever the 
sensor contact 40 is tripped. This picture may be 
transmitted over communications network 16 and stored 
in database server 48. When contact sensor 40 detects 
that the front door has been opened, an event 
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descriptor 49 may also translate the signals received 
from monitoring module 28 into the specific electrical 
signals that are required to communicate with (both 
input and output) and control its associated device 32. 
Device descriptor 49 may be provided for each specific 
device 32 when, for example, different devices 32 have 
different interfaces and require specific sets of 
electrical signals for their monitor and control. 

Device descriptors 49 may include, for 
example, a manufacturer identification, product 
identification, and driver version number to allow a 
device to be referenced correctly. Once a new device 
32 has been detected and is to be integrated into the 
system, monitoring module 28 may reference, download, 
and run the appropriate drivers for the new device. 

After loading a new descriptor 49, monitoring 
module 2 8 may communicate with remote site 14 to 
determine whether device 32 has been previously 
catalogued. Monitoring module 2 8 may, for example, 
determine if a general description and a default state 
of device 32 exists at the remote site. When a device 
32 has been catalogued, then, for example, static 
parameters, such as the manufacturer name, may be 
communicated from monitoring module 2 8 to remote site 
14 and the default state of device 32 may exist at 
remote site 14. When a device 32 is not already 
catalogued, device 32 may communicate its default state 
and static parameters to monitoring module 28 that may, 
in turn, communicate the default state and static 
parameters to remote site 14. The communication from 
monitoring module 28 to remote site 14 may be done 
using name/value pairs using, for example, the normal 
HTTP post method discussed hereinbefore. For example, a 
template document may be a static parameter of device 



FIG. 3 shows five devices, 32, 32a, 32b, 32c, 
32d. In practice, there may be more or fewer devices 
with each installation. Each device may be interfaced 
to a monitoring module 28 via a device descriptor or 
driver 49 (only one shown) . Each device may include a 
customizable user interface 58 that may be viewable on 
a remote user access device over communications network 
16. Interfaces 58 may include virtual representations 
of the actual user interfaces of the devices. 

In another approach, virtual representations 
may be stored on, for example, web server 46. Remote 
site 14 may use changes in device states to change the 
virtual representations of the devices with which the 
changed states are associated. A virtual 
representation of a device, as previously described, 
may be either a text-based, symbol -based, or image- 
based representation of an actual device 32 from the 
installation as it appears to a user who accesses the 
remote site from a location remote to the installation 
using any suitable remote user access device. For 
example, if the device is a light switch, the 
corresponding virtual representation may be an 
indicator icon that may be either green or red. If the 
indicator icon is green, that may denote that the 
actual light switch is in the "on" position. If the 
indicator is red, that may denote that the light switch 
is in the "off" position. If, during a heartbeat 
operation, remote site 14 is informed that the state of 
the light switch changes from "on" to "off," then the 
virtual representation of the light switch may change 
from being green to being red. 

User interface 58 may include at least one 
resource. In the example of FIG. 3, resources 60, 62, 



- 21 - 



and 64 are shown. Resources may provide users with 
access to features specific to their associated device. 
For example, the device shown in FIG. 3 represents a 
videocassette recorder (VCR) having a recording setting 
5 resource 60, a channel selecting resource 62, and a 
power selecting resource 64. Typical VCRs may have 
other operational resources, but the resources 
illustrated in FIG. 3 are sufficient to illustrate the 
operation of the device. 

10 Each resource 60, 62, 64 may include one or 

more display components. For example, the recording 
setting resource 60 includes a display component 70 and 
a series of pushbuttons 72, 74, 76, 78 which a user may 
use to activate the VCR's fast forward, reverse, play, 

15 and stop functions, respectively. The channel 

selecting resource 62 may include the display component 
70 and a pair of pushbuttons 82 that users may use to 
activate up channel and down channel functions of the 
VCR. The power selecting resource 64 may include a 

20 toggle switch 80 that user may use to activate the 
VCR's power on and power off commands, and an LED 
indicator 81 that may indicate the power condition of 
the VCR. 

Other suitable display components may include 
25 toggle buttons, radio buttons, absolute sliders, 

proportional sliders, edit fields, labels, images, 
video clips, streaming video, streaming audio, 
multiselect list, time fields, date fields, N- 
directional components, N-state buttons, N-state 
30 selectors (where N may be any suitable integer) , trees, 
tables, graphs, charts, drawing pads, streaming audio, 
banners, or any other suitable display components. 
Display components may act as status indicators. If 
desired, display components allow users to toggle 



settings or otherwise manipulate devices 32. For 
example toggle buttons may serve as indicators, 
showing, for example, whether a device is in the "on" 
position or in the "off 11 position. Toggle buttons may 
allow users to change the state of a device, by, for 
example, turning a device on or off. Sliders may act 
as indicators by showing, for example, the percentage 
complete of a particular process a device may be 
performing (e.g., baking a cake), and may allow users 
to change the state of a device (e.g., changing the 
thermostat temperature) . Edit fields may allow users 
to change textual representations of suitable elements 
(e.g., naming a television show to be recorded by the 
show's name). Video, audio, images, or any other 
suitable media-based components may act as indicators 
showing what the devices are sensing (e.g., images may 
be sensed by cameras, streaming video may be sensed by 
camcorders, audio clips may be sensed by audio 
recorders, etc.). Date and time fields may act as 
indicators, by, for example, displaying what date and 
time a VCR is set to start recording. Date and time 
fields may allow users to set the date and time a VCR 
may start recording. Multiselect lists may act as 
indicators by, for example, listing all sound sensors 
that are detecting noise in the house. Multiselect 
lists may also be used, for example, to select some of 
a number of available sensors to turn on. 

A virtual representation of each device 32, 
32a, 32b, 32c, 32d may be stored as a record 94, 94a, 
94b, 94c, 94d in the database of database server 48 of 
remote site 14. Each record may contain an entry for 
each resource and its associated components which make 
up the device. For example, record 94 for VCR device 
32 may contain an entry 90, 91, 92 for each resource 
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60, 62, and 64, respectively, and an entry 90a, 90b, 
90c, 90d, 91a, 91b, 92a, and 92b for each component 70 
72, 72, 74, 80, 81, and 82, respectively. In addition 
a web page 4 7 may be generated by web server 4 6 by 
extracting the associated record for that device from 
database server 48 and creating a graphical, textual, 
tactile, aural, or other similar modality user 
interface representation of that device that the user 
may access via, for example, Internet browser 26. 

One of the functions that monitoring module 
28 may serve is to persist the state of devices 32. 
This may be done, for example, to allow the real-time 
states of devices 32 to be stored, to communicate to 
remote site 14, or to allow for easy recovery from a 
system crash. 

The stored state of devices 32 may also be 
used for maintaining a synchronized relationship 
between an installation 12 and remote site 14. In one 
possible embodiment of the present invention, remote 
site 14 and installation 12 may use polling and 
heartbeat mechanisms in order to synchronize state 
information between remote site 14 and installation 12. 
Polling may refer to a process whereby monitoring 
module 28 obtains commands from remote site 14. The 
commands may reside, for example, in command queue 51. 
Commands may be accumulated at command queue 51 as a 
result of any suitable action by the user, by remote 
site 14, or by both. For example, a user may use a 
remote user access device to issue a command or a 
request to remote site 14 to cause a change in state of 
one of devices 32 (e.g., to turn a lamp on) . Remote 
site 14 may post the change in state command to a 
command queue 51. 

Monitoring module 2 8 may communicate a 
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request for pending commands to remote site 14 . This 
request may be communicated periodically as part of the 
polling process. In response to the monitoring 
module's request, remote site 14 may provide one or 
5 more pending commands from command queue 51, and may 
notify monitoring module 28 of the number of remaining 
pending commands in command queue 51. Monitoring 
module 2 8 may then again communicate a request for 
pending commands. Remote site 14 may return more of 

10 the pending commands from command queue 51. This 

process may continue until command queue 51 at remote 
site 14 is empty. 

Remote site 14 may provide commands to 
monitoring module 2 8 using any suitable algorithm. For 

15 example, remote site 14 may return commands using 

first-come, first-serve, round robin, first-in, first- 
out, weighted prioritization, or any other suitable 
algorithm. Remote site 14 may also proactively inform 
monitoring module 2 8 that commands are waiting in queue 

20 51. Monitoring module 28 may then poll remote site 14 
and retrieve commands from remote site 14 until the 
queue is empty. 

Whereas polling process 50 is used by remote 
site 14 to effect state changes in devices 32 via 

25 monitoring module 28, monitoring module 28 may use 

heartbeat process 52 to update device state information 
at remote site 14 . A heartbeat may be a periodic 
communication from monitoring module 28 to remote site 
14 containing updated state information for devices 32 

30 associated with monitoring module 28. In one suitable 
heartbeat process 52, monitoring module 2 8 may send a 
communication to remote site 14 in response to a change 
in state of a device 32, a synchronization of a device 
32 with remote site 14, a triggered alert event, or in 
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response to any other suitable event. In such a 
heartbeat operation 52, all data intended to be 
transmitted to remote site 14 may be transmitted to 
remote site 14 via communications network 16. Remote 
5 site 14 may transmit an acknowledgment of receipt and 
successful processing of the data back to monitoring 
module 2 8 . 

Remote site 14 may direct monitoring module 
2 8 to make changes in its own state by, for example, 

10 posting commands to data store 51. For example, remote 
site 14 may post commands that set or modify the 
polling 50 or heartbeat 52 time intervals. Upon 
reaching the end of the current polling interval, 
monitoring module 2 8 may send a communication to remote 

15 site 14, requesting any queued commands. Monitoring 
module 28 may continue to poll, using a preselected 
communication scheme, until the queue of commands 
waiting for monitoring module 2 8 is empty. Each 
command received from the queue may be acted upon when 

20 the command is received and any associated state 

changes are effected. Remote site 14 may transmit an 
acknowledgment of receipt and successful processing of 
the data back to monitoring module 28. 

If desired, remote site 14 may send 

25 unsolicited communications to monitoring module 28. 

Remote site 14 may send communications to, for example, 
set or update the heartbeat or polling time, or to 
cause monitoring module 28 to issue a command to update 
a component of a device. Remote site 14 may send 

30 unsolicited communications to monitoring module 28 for 
any other suitable purpose. 

In addition to maintaining the polling and 
heartbeat operations and exchanging communications for 
events, data, and commands 54 with remote site 14, 
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monitoring module 28 may also take care of many network 
level activities 56. These activities may include, but 
are not limited to verifying passwords, dialing up an 
ISP, if necessary, periodically uploading 
5 accounting/billing information, and performing security 
measures. Any other suitable network level activities 
may be performed by monitoring module 28. 

The present invention may provide a 
registration process. The registration process may be 

10 used to allow the registration of new users, monitoring 
modules, and available devices at remote site 14. 
Using information from the registration process, remote 
site 14 may provide the registered user with access to 
the functionalities of the registered monitoring module 

15 and registered devices. Users may access the 
functionalities of the modules and devices via 
communications network 16. 

A user or users of installation 12 may open 
an account with remote site 14 to use services offered 

20 by remote site 14. For example, the user or users of 

installation 12 may open an account with remote site 14 
by accessing web server 46 of remote site 14 via, for 
example, web browser 26. If desired, accounts may be 
opened using any other suitable approach, such as, for 

25 example, using a telephone, or mailing in a physical 
contract. Information provided for the purposes of 
opening an account with remote site 14 may be stored in 
database server 48. 

In one suitable embodiment of the present 

3 0 invention, users may be required to create accounts 
before installations, monitoring modules, devices, 
components, virtual representations, or other elements 
of the system that are associated with a particular 
user or entity may be registered with remote site 14. 
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Subsequent access to the registered installations may 
be granted only to the user account holder or to those 
that the user account holder has permitted access. 
FIG. 4 is flow chart of illustrative steps involved in 
5 associating registered installations (and the 
registered elements making up the registered 
installations) with a particular user account. At step 
306 a user account is created. Registration of the 
user's installations takes place at step 308. Step 308 

10 may include steps 309 and 311. At step 309, 

appropriate database entries may be made in database 58 
that catalog the elements to be registered (which may 
effectively serve to register the elements at remote 
site 14) . At step 311, remote site associates the 

15 registered elements with their corresponding user 

account. This may be done using any suitable cross- 
referencing technique. For example, in a relational 
database, a separate table may list all installations 
in one field and the corresponding user accounts in 

20 another field. Another table may list all 

installations in one field (that may act as a key field 
to the first table) and all associated elements in 
another field. This is merely an illustrative 
relational database structure for cross-referencing 

25 installations and their elements with corresponding 
user accounts. Any other suitable database construct 
may be used. 

Once the registration process is completed, 
the user account holder and those entities that the 

30 user account holder permits access to, may access the 
registered installations at step 310. 

Monitoring modules 28 may also register with 
remote site 14. Information regarding monitoring 
modules 28, such as model identification, attached 
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devices, etc. may also be stored in database server 48. 
Once a monitoring module is registered, it may register 
its attached devices with remote site 14 . Information 
associated with devices, such as device names, may be 
5 stored in database server 4 8 and made available to the 
user. Each device 32 may communicate with monitoring 
modules 28 and export its customized interface to 
database server 48. If the interface is not 
customized, a default interface may be used. 

10 The registration process of the present 

invention may require user interaction locally, 
remotely, or both. For example, the system may prompt 
users to enter registration information on a web site 
that is resident on web server 46. The system may, for 

15 example, require users to set or adjust system settings 
using set-up software running locally on user access 
device 22. The set-up information may subsequently be 
communicated to remote site 14. Any suitable 
combination of local and remote registration processes 

20 may also be used. 

FIGs. 5-9A, 10, 11, and 17 are illustrative 
displays that the system may provide to the user during 
the registration process. Although the displays shown 
in FIGs. 5-9A, 10, 11, and 17 are shown as web pages, 

25 it should be understood that the displays need not be 

limited to being displayed in a web browser or using an 
Internet-based or client-server based approach. For 
example, the displays may be generated by web server 
46. The displays shown in FIGs. 5-10, 15, and 16 are 

30 merely illustrative. If desired, any other suitable 
displays may be used. FIG. 5 shows an illustrative 
service agreement display that the system may provide 
as one of the first screens in the registration 
procedure . When the user agrees to the terms of the 
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service agreement, the system may then prompt the user 
for personal information as shown in FIG. 6. The 
system may, for example, prompt the user for a login 
identifier and password. 
5 The system may provide the user with 

opportunities to set names or identifiers for 
monitoring modules and/or connected devices. FIG. 7 
shows an illustrative display listing devices for a 
particular installation and the devices' corresponding 

10 names and/or descriptions. The system may provide the 
user with an opportunity to enter names for the 
monitoring module, the devices, or both, during the 
registration process. If desired, an entire 
installation may be given a name chosen by the user. 

15 FIG. 8 shows an illustrative display that prompts the 
user for an installation name. 

If desired, the system may provide displays 
instructing users how to connect various devices and 
how to register them with remote site 14. FIG. 9A 

20 shows an illustrative display having instructions on 
how to connect a camera to the monitoring module in 
order for the camera to be automatically detected and 
registered with remote site 14 . 

Automatic detection of devices may be 

2 5 implemented using any suitable software, hardware, or 
both that may allow devices coupled to a monitoring 
module to be automatically detected. The approach 
employed for implementing automatic detection may 
depend on whether there is one-way communications 

30 between devices 32 and monitoring module 28 (i.e., from 
devices 32 to monitoring module 28) or whether there is 
two-way communications . 

In one suitable approach monitoring modules 
may continuously, periodically, or in response to one 
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or more particular events, attempt to handshake with 
devices. This is illustrated by FIG. 9B . The 
monitoring module may send a handshake message through 
all of its interface ports (e.g., USB, parallel, 
5 serial, IEEE 13 94, infrared, proprietary, and any other 
suitable wired or wireless based port) in an attempt to 
reach all devices that may possibly be coupled to the 
monitoring module (step 2 00) . The monitoring module 
may use any suitable algorithm in sending handshake 

10 communications to its interface ports. For example, 
the communications may be sent sequentially, using 
round robin, weighted fair queuing, or any other 
suitable algorithm. If a device is coupled to the 
monitoring module the handshake communication may be 

15 sent to the port to which the device was connected 

(step 2 02) . At step 2 04, the device may respond to the 
handshake communication (e.g., with another handshake 
communication) . If a response is received by the 
monitoring module, then at step 206, the device that 

2 0 communicated the response is detected by the monitoring 
module. The monitoring module may then request 
additional information from the detected device (e.g., 
to use in the registration process) . If no response is 
received from a particular port, then a device is not 

25 detected at that port. 

If devices are daisy-chained, the handshake 
may be passed on from one device to another in the 
chain. Responses from the daisy-chained devices may be 
returned from one device to the next until the 

30 responses reach the monitoring module. 

The use of handshakes is merely an 
illustrative approach for the automatic detection of 
devices. Any other suitable approach may be used. For 
example, a monitoring module may check its ports to 
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determine whether any data streams are coming into the 
ports. For example, in the case where the device is a 
video camera, a constant video feed may be communicated 
from the video camera to the monitoring module. If 
5 there is a data stream coming in, then the monitoring 
module may acknowledge that a device is coupled to that 
port. FIG. 9C illustrates this method of automatic 
detection of devices. At step 208 a device may be 
coupled to the monitoring module. The device may 

10 transmit a data stream at step 210. At step 212, the 
monitoring module may check ports for data streams and 
may detect a data stream (step 214) at the port 
corresponding to the device. 

In another suitable approach, devices may be 

15 configured to periodically, continuously, or upon 
particular events (e.g., power-up, user pressing a 
button, or any other suitable event) send a message 
through their respective connection interfaces, 
identifying themselves. For example, each device may 

2 0 have a user interface such as a button that a user may 
need to interact with (e.g., pressing the button) in 
order for the device to be detected. For example, upon 
user interaction, the device may send a communication 
to its corresponding monitoring module. The 

2 5 communication may be any suitable communication that 
may allow the monitoring module to detect the device. 
In one suitable embodiment, the communication may 
include a serial number associated with the device. 
The serial number may be used by the monitoring module 

30 to identify the device in subsequent processes. If 
desired, this approach may be used with wireless 
devices (i.e., devices 32 that communicated with 
monitoring module 28 via a wireless interface such as 
Bluetooth) , while wired devices may be detected using 
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any other suitable method. 

Any other suitable approach for the automatic 
detection of devices may be used. For example, the 
monitoring module may detect whether electrical current 
5 is flowing through device ports as a means of detecting 
devices (in the case of wired devices) . In such an 
embodiment, the device may change the state of an 
interface element (e.g., a connection pin) between a 
high value and a low value depending on whether power 

10 is being sent through the port to the device. For 

example, if a video camera is coupled to the monitoring 
module, the video camera may be automatically powered 
by the current from the monitoring module. The flow of 
current may cause the value of a particular connection 

15 pin to change from low to high. The monitoring module 
may detect the high value of the particular connection 
pin, thus indicating the presence of a device. 

In another suitable approach, the devices and 
monitoring modules may be configured according to hot- 

2 0 plugging standards (e.g., that make use of IEEE 13 94, 
USB, PCMCIA, or any other interface that accords with 
hot -plugging standards) . Any such suitable approach 
may be used. 

In one suitable embodiment of the present 

25 invention, a detected device may communicate a unique 

string to the monitoring module. The unique string may 
be used by the monitoring module to detect the device 
or the unique string may be communicated subsequent to 
the detection of the device. The unique string may 

30 contain a uniform resource identifier (URI) , such as, 

for example, a uniform resource locator (URL) . The URI 
may provide a link to a downloadable object, such as, 
for example, a remote method invocation (RMI) , a common 
object request broker architecture (CORBA) object, a 
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distributed component object model (DCOM) object, a 
device driver/device descriptor, or any other suitable 
downloadable object. The downloadable object may be 
acquired by monitoring module 28 (using, for example, 
5 communication network 16) . The downloadable object may 
be installed at monitoring module 28. The object may 
be executed and may take responsibility for running the 
corresponding device, registering parameters, 
registering events, registering components, or for 

10 performing any combination of these or any other 
suitable functions . 

FIG. 10 shows an illustrative display showing 
which devices have been detected. The registration 
process may provide users with opportunities to set up 

15 or customize the detected devices in any suitable way. 
For example, the system may allow the user to rename 
any device, as in the illustrated example, to set 
parameters for detected devices (e.g., setting a 
digital camera's resolution, setting default settings 

20 for device, etc.), or to customize the devices in any 
other suitable way. 

Other information that monitoring module 2 8 
may supply to remote site 14 during the registration 
process may include information about the type of 

25 communications network 16 being used by the client 
access device to communicate with remote site 14 . 
FIG. 11 is an illustrative display that may be 
displayed for the purpose of requesting this 
information. Any suitable information may be supplied 

3 0 to remote site 14 during the registration process, 

including, for example, information regarding client 
device 22, parameters for devices 32, and information 
regarding any particular software or hardware component 
of installation 12. 
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The monitoring module may generate a globally- 
unique monitoring module identification and a 
monitoring module password during the registration 
process. These are illustrated in FIG. 12. Every 
monitoring module 28 may have a model identification 
code, identifying the particular model of the 
monitoring module. During the registration procedure, 
or at any other suitable time, the monitoring module 
may generate a monitoring module identification 116 and 
a monitoring module password 118. If desired, the 
monitoring module identification 116 and a monitoring 
module password 118 may be predetermined and stored in 
memory in the monitoring module during the 
manufacturing process. The monitoring module 
identification may be unique to each particular 
monitoring module in the whole set of existing 
monitoring modules. This is merely an illustrative 
embodiment of the monitoring module, and any other 
suitable embodiment may be used. 

Monitoring module 28 and remote site 14 may 
communicate using a communications protocol. The 
communications protocol between monitoring module 28 
and remote site 14 (e.g., via communication network 16) 
may consist of a series of predefined messages, message 
parameters, and return codes. The registration 
protocol may be a subset of this communications 
protocol and may be specific to the registration 
process used to register monitoring modules and devices 
with remote site 14 . 

Registration protocol messages may be 
initiated by the monitoring module. The monitoring 
module may, for example, generate a transaction 
identification for each message. The transaction 
identification may be an identifier that is unique 



within a given time window. Registration protocol 
messages may include, or be accompanied by, the 
transaction identification, model identification code, 
monitoring module identification, and monitoring module 
password. The registration protocol message may 
include commands and any required command-specific 
parameters. If desired, any suitable part of the 
system other than the monitoring module may initiate 
the communication of registration protocol messages. 
For example, the user may manually initiate the 
registration protocol messages using, for example, 
client device 22. 

Remote site 14 may process monitoring module 
registration messages and return confirmation messages 
to the monitoring module that initiated or generated 
the registration messages. The confirmation message 
may contain the original message's transaction 
identification, a version identification of the 
software being used at web server 46, database server 
48, or both, and the name or other identification of 
the command to which the confirmation is responding. 
If desired, confirmation messages may include any other 
identification information or other suitable 
information instead of or in addition to those 
described . 

Confirmation messages may also include an 
acknowledge character (ACK) to indicate remote site 14 
processed the message correctly. When remote site 14 
cannot process the message correctly, for whatever 
reason (e.g., checksum error, invalid command 
parameter, etc.), confirmation message may include a 
negative-acknowledge character (NAK) code. The 
confirmation message may also include an error message 
that may indicate the reason for the NAK code. 
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In one suitable approach, remote site 14 may- 
have the ability to recognize certain errors, forms of 
errors, or both. Remote site 14 may also correct the 
recognized errors. Instead of returning a NAK code in 
5 this situation, remote site 14 may return an ACK code 
with a notification of the detected error and the fact 
that it was corrected. Alternatively, remote site 14 
may only return an ACK code without the acknowledgment 
that an error was corrected. Any such suitable 
10 response may be used. 

If desired, multiple registration protocol or 
other messages may be sent using only one 
communication. This may be accomplished using any 
suitable technique. For example, the messages may be 
15 bundled into an extensible markup language (XML) 

command schema. Remote site 14 may, likewise, respond 
to the bundled message communication in one XML 
confirmation schema. Alternatively, remote site 14 may 
provide individual responses for each command in the 

2 0 original communication. 

FIG. 13 shows illustrative steps involved in 
the registration process. It should be understood that 
the steps shown in FIG. 13 may be altered in any 
suitable way. For example, steps may be added, 
25 deleted, or performed in any suitable order. 

FIG. 13 is merely an illustrative embodiment of the 
registration process. Any suitable modifications may 
be made in accordance with the present invention. In 
the first series of steps 100, the monitoring module 

3 0 may generate a monitoring module identification, a 

monitoring module password, a model identification 
code, and a transaction identification. Registration 
information from devices 32, coupled to the monitoring 
module may be extracted. These pieces of information 
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may be included in a registration message that is 
communicated to remote site 14 by monitoring module 28 
at step 102 . 

At step 104, remote site 14 may check the 
5 validity of registration messages, of command (or 
commands) included in the registration messages, or 
both. Checking message validity may include, for 
example, checking whether a message has a transaction 
identification that is unique within the agreed upon 

10 time window; checking whether a message includes a 
unique monitoring module identification and a 
monitoring module password; and checking whether a 
message includes a model identification code. If 
desired, any other suitable technique may be used in 

15 checking message validity. Checking message command 
validity may include, for example, determining whether 
a command is one that remote site 14 is able to 
recognize (i.e., is an actual predefined command); and 
whether a message includes the correct command 

20 parameters for the command used. If desired, any other 
suitable technique may be used in checking message 
command validity. If desired, remote site 14 may also 
check for command specific validity. This may involve, 
among other things, ensuring that any contingent 

25 devices have already been registered, checking to make 
sure a device that is to be registered has not already 
been registered, and any other suitable validity 
checks. FIG. 14 shows illustrative commands, 
corresponding command parameters, and corresponding 

30 command validity checks for the registration process. 
If desired, any other suitable commands may be used. 

If there are no errors, remote site 14 may 
register the installation, including the monitoring 
module, devices, resources, components, virtual 
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representations, and any other suitable elements of the 
installation. If desired, any of the elements may also 
be registered separately from other elements. Remote 
site 14 may also associate the registered elements with 
5 the corresponding user account. Registering monitoring 
modules 28 and devices 32 may include, for example, 
adding the identified monitoring module, devices, user, 
or any other suitable information contained in the 
registration message, to a database at remote site 14. 

10 Remote site 14 may then generate a confirmation message 
that includes, in the case of no errors, an ACK. When 
errors are encountered during the registration process, 
remote site 14 may return a NAK. At step 106, the 
confirmation message may be transmitted from remote 

15 site 14 to the monitoring module. At step 108, the 

monitoring module checks the confirmation message. If 
a NAK is found, then the monitoring module may 
retransmit the registration message at step 112. If an 
ACK is found then the registration is deemed to be 

20 successful at step 110. 

Information regarding registered monitoring 
modules and registered devices may be stored in the 
database. Remote site 14 may access the database to 
retrieve information about the registered monitoring 

25 module (or monitoring modules) and registered devices. 
The system may provide the user with the ability to set 
preferences for the registered devices, gather 
information from the registered devices, and control 
the registered devices. The database may allow for an 

30 efficient mechanism by which information about devices 
may be accessed and provided to the user. An 
illustrative database schema is shown in FIG. 15. If 
desired, any other suitable schema may be used. 

When a user registers with remote site 14, a 
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number of table entries in the database may be created. 
The user's personal information, billing information, 
the monitoring module's unique monitoring module 
identification, the monitoring module password, and any 
5 other suitable data may be stored in the database. 

Entry of the data into the database may be facilitated 
by using an appropriate database application program 
interface (API) , such as, for example, an API with a 
data parameter that may create a data cell and store 

10 the content of the data parameter in the data cell. 
Thus, only a single function call may be needed for 
entering a piece of data into the database. Once a new 
user is added to the database, the function may return 
a user identification code or number. This user 

15 identification may be used by the system to refer to 
the user rather than having to use the user's name. 

The process for adding entries for monitoring 
modules and devices in the database may be similar to 
the process for adding entries for users. That is, 

2 0 using APIs, new table entries may be added in the 

database. When registering new monitoring modules and 
devices, only a single function may need to be called 
by web server 4 6 to create the appropriate table 
entries in database 58. The appropriate table entries 

25 may be created and the appropriate identification codes 
or numbers may be returned. If desired, any other 
suitable technique for adding entries for monitoring 
modules and devices in the database may be used. 

When processing validity checks, web server 

30 46 may query the database to determine whether certain 
entries are already in existence. For example, when 
registering a new device, a function may be called by 
web server 46 that returns a boolean value 
corresponding to whether or not the device already 
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exists in the database. This querying process may be 
performed using suitable API's. 

Although the illustrated system uses APIs as 
an interface between database server 4 8 and web server 
5 46, other suitable technologies may be used. For 

example, Perl scripts, CGI scripts, Cold Fusion, or any 
other suitable technologies, or combination thereof, 
may be used to interface database server 4 8 with web 
server 46. 

10 FIG. 16 illustrates a relationship between 

web server 46 and the database. Generally, 
communication between the database and the world wide 
web site may be done through the use of API functions. 
The web server may call a particular API function that 

15 causes the database to be accessed. The API may then 

return a value (in accordance with the specification of 
the particular function) that is sent to the web 
server. This is merely an illustrative way of allowing 
the web server to interact with the database. If 

20 desired, any other suitable way of allowing the web 
server to interact with the database may be used. 

Users may also edit preferences for 
registered devices. For example, the system may 
provide users with opportunities to set up special 

25 notification preferences for particular devices. 

FIG. 17 shows an illustrative display. The display 
shows a listing of event descriptions and the 
corresponding notifications set up for each event 
description listing. The user may be given the ability 

30 to edit the notification action. 

In one suitable embodiment of the present 
invention, registration of a device 32 may entail the 
registration of actions and indicators associated with 
that device. An action may be an action that a user 
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may take with respect to a corresponding device 32 from 
a remote location using, for example, remote user 
access device 17. For example, a user accessing a web 
site using user access device 17 and turning up the 
5 brightness level of a video camera at installation 12 
may be a suitable action. An indicator may be used to 
provide information regarding particular feedback from 
a corresponding device 32. For example, the current 
frame rate of a video camera may be a suitable 
10 indicator . 

In another suitable embodiment of the present 
invention, the registration process may be layered with 
sub-registration processes for registering users, 
registering installations associated with their 

15 respective users, registering monitoring modules 

associated with their respective installations (and, in 
turn, associated with their respective users) , 
registering devices associated with their respective 
monitoring modules, registering resources associated 

20 with their respective devices, registering components 
associated with their respective resources, and 
registering virtual representations which are made up 
of components to provide a virtual device. This is 
illustrated by step 304 of FIG. 4. 

25 The registration process for each of these 

layers may include registration information being sent 
from the monitoring module to the remote site, 
including suitable registration commands and parameters 
(e.g. , addComponent (Resource, monitoringModule , 

30 componentType , etc.)). Registration messages for the 
different layers may be generated using a markup 
language (e.g., HTML) . For example, HTML form post 
commands with name/value pairs may be used in the 
registration message. When the registration message is 
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communicated to the remote site, web server 46 may 
process the registration message by parsing the markup 
language code. Appropriate entries may be made into 
database 58 at remote site 14 to catalog the registered 
elements of an installation. 

Each registered element may be assigned a 
suitable identification code by remote site 14 that may 
be used to identify at remote site 14 the element 
within a particular installation. In one suitable 
approach, monitoring module 28 may assign an 
identification to an element of installation 12 that is 
unique only to installation 12 or to monitoring module 
28. The identification assigned by monitoring module 
2 8 may or may not be made identical to the 
identification code assigned by remote site 14. In the 
approach where the identifications are different, the 
identification code assigned by remote site 14 may be 
mapped to the identification assigned by monitoring 
module 28 (e.g., using appropriate database 
constructs) . When communicating with monitoring module 
2 8 regarding a particular element, remote site 14 may 
look up the mapped identification assigned by 
monitoring module 2 8 and communicate using that 
identification. In the case where the remote site 14 
and monitoring module 28 use the same identification, 
the identification assigned by remote site 14 may be 
returned to monitoring module 28. Monitoring module 28 
may use the identification in subsequent communications 
with remote site 14 when referring to the element of 
installation 12 with which identification is 
associated . 

Virtual representation registration may 
involve a template document being registered with the 
remote site. A template document may be a description 



of the layout. of components (i.e., virtual 
representations of actual device components) that may 
be used to generate a web page displaying the 
components. A markup language, such as, for example, 
HTML may be used to generate a template document. A 
template tag may be used that may take the form of 
<component id = XX>, where "id" may be used to 
designate a particular component. The tag may be 
followed with code (e.g., HTML code, Javascript, etc.) 
that may include state information of the particular 
component, or any other suitable information. When a 
user accesses a registered virtual representation (of a 
registered device) via, for example, web page 47, 
remote site 14 may collect all of the components 
associated with the device as well as the template 
document for the virtual representation of the device. 
Remote site 14 (e.g., web server 46) may generate a web 
page that may include a collection of code that was cut 
and pasted from the template document, producing a 
virtual representation of the device. 

Users that access the virtual representation 
of the device may make any suitable changes to the 
individual components (e.g., that correspond to state 
changes of the corresponding device) and those changes 
may be communicated to monitoring module 28. In one 
suitable embodiment, the actual state of components may 
not be altered in database 58 when the changes are 
issued by suitable users through, for example, browser 
26. Rather, upon monitoring module 28 receiving state 
changes via, for example, packaged commands from queue 
51, the commands may be delivered to an appropriate 
device descriptor 49. Device descriptor 49 may be 
responsible for communicating a command to remote site 
14 for the purpose of updating database 58 with the 
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respective state changes. The communication from 
device descriptor 49 may confirm the acceptance of the 
state changes. Changes in display components of a 
device's virtual representation may signal that a 
5 corresponding change is or has been performed in 
physical device 32. 

FIG. 18 is a flowchart of illustrative steps 
involved in registering a virtual representation of a 
device. At step 400 a template document is generated. 

10 The template document may be generated at the 

monitoring module, at the device, or at any other 
suitable location. The monitoring module may 
communicate registration information at step 402. The 
registration information may include registration 

15 information for the monitoring module, devices, 

resources, components, and virtual representations of 
devices. The registration information may also include 
the template document that may include information 
related to components. At step 4 04, the remote site 

20 may use the registration information to register, among 
other things, the virtual representation of the device, 
including the template document. 

This is merely an illustrative approach of 
registering a virtual representation. Any other 

25 suitable approach may be used. For example, the 

present invention is not limited to using HTML, but may 
make use of any suitable markup language or any 
suitable language, in general, to code registration 
information. If desired, template documents need not 

30 be communicated by monitoring module 28 to remote site 
14. Any suitable URI such as, for example, a URL, may 
be communicated that may direct remote site 14 to a 
corresponding template document . In another suitable 
approach, multiple template documents or one or more 
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URIs linked to multiple template documents may be 
registered in connection with a particular virtual 
representation. For example, a device's virtual 
representation may have a main layout for resources, 
5 which may each have a template for their respective 
components . 

In one suitable embodiment of the present 
invention, events may be registered at a remote site. 
An event may be specific to a particular device. For 

10 example, "FIRE!!!" may be a unique event to a fire 

alarm device, whereas "door motion sensor tripped" may 
be a unique event to a door motion detector device. 
Any such suitable events may be associated with their 
respective suitable devices. 

15 In one suitable embodiment of the present 

invention, as new devices are added to a registered 
monitoring module, the monitoring module may 
automatically (i.e., without any user interaction) 
detect the presence of the new devices and 

20 automatically notify remote site 14 of the presence of 
the new devices. Remote site 14 may, in turn, add the 
new devices to the database. In order to determine 
when and which new devices are added, the monitoring 
module may conduct object discovery on a continuous 

25 basis. If desired, the object discovery may be 

conducted on a periodic basis. Once new devices are 
found, the monitoring module may send a registration 
message to remote site 14 in accordance with the 
present invention. This process is shown in FIG. 19. 

30 In some suitable embodiments of the present 

invention an installation 12 may be re-registered. For 
example, in the case where a system crash occurs at an 
installation 12, or if the hardware, software, or both 
is upgraded at the installation (or at the remote 
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site) , the installation may need to be re-registered. 
Re-registration may be necessary for any suitable 
reason. The process for re-registration may be 
substantially similar to the initial registration 
5 process for an installation, monitoring modules, 

resources, components, and virtual representations. 

In one suitable approach, remote site 14, 
remote user access devices 17, or any other suitable 
remote elements of system 10 may access installation 12 

10 or any of the elements of installation 12 using a 

special address (e.g., IP address) that is associated 
with a particular installation 12 or with a particular 
element of installation 12. The special address may be 
communicated from the corresponding installation or 

15 element of an installation during the registration 
process . 

Thus, systems and methods for the automatic 
registration of devices are provided. One skilled in 
the art will appreciate that the present invention can 
20 be practiced by other than the described embodiments, 
which are presented for purposes of illustration and 
not of limitation, and the present invention is limited 
only by the claims which follow. 



